Typically, process plants (such as chemical refinery plants and drug manufacturing plants, for example) include many field devices which control and measure parameters within the process. Each field device may be a control device (such as a flow valve controller), a measurement device (such as a temperature gauge, pressure gauge, flow meter, etc.) and/or any other device that affects or determines a value associated with a process. Until the past decade or so, field devices have typically been rather simple devices which were controlled either manually or electronically and which produced output readings either electronically or on a gauge connected to the device. However, these devices typically only provide limited information to a controller such as analog signals pertaining to the readings or measurements made by these devices.
More recently, so called "smart" field devices have been developed. Smart field devices are capable of communicating with a process controller and/or a management system associated with the device. Typical smart field devices are capable of transmitting an analog signal indicative of the value associated with the device, for example, a measurement value, and of storing and also digitally transmitting detailed device-specific information, including calibration, configuration, diagnostic, maintenance and/or process information. Some smart devices may, for example, store and transmit the units in which the device is measuring, the maximum ranges of the device, whether the device is operating correctly, troubleshooting information about the device, how and when to calibrate the device, etc. Furthermore, a smart field device may be able to perform operations on itself, such as self-tests and self-calibration routines. Exemplary smart devices include devices which follow the HART (Highway Addressable Remote Transducer) protocol (HART devices), the Fieldbus protocol (Fieldbus devices), the Modbus protocol, and the DE protocol. However, other smart device protocols may exist or be developed in the future to support different types of smart devices.
Currently, every conventional and smart device is capable of performing one or more specific input and/or output functions with respect to a process. An input function is any function which measures or reads a value associated with a process, such as the function performed by a temperature or pressure measurement device. An output function is any function that changes something within a process, such as the functions performed by a valve or flow controller. Furthermore, some smart devices, such as Fieldbus devices, can perform control functions which are functions associated with the control of a process. Each input, output and control sub-function performed by a device is referred to as a "block." By definition, therefore, each device includes at least one, and maybe more, blocks. Fieldbus devices usually include multiple blocks (e.g., one or more input, output, and control blocks), and while HART devices do not include blocks, per se, the contents of a HART device are often conceptualized by those skilled in the art as constituting one and only one block (a "conceptual" block).
Each block and, therefore, each device includes one or more "parameters." A parameter is an attribute of a block which characterizes, affects or is somehow otherwise related to the block. Parameters may include, for example, the type of the block, the maximum operating or measurement range of a block, the mode of a block, the value of a block measurement, etc.
Likewise, each parameter has one or more properties associated therewith, and each of those properties defines or describes the information within the parameter. For example, the temperature parameter of a temperature measuring device has a label property which stores the name of the parameter (e.g., "temperature"), a value property which stores the value of the parameter (e.g., the actual measured temperature), and a units property which stores the units in which the temperature value is expressed (e.g., degrees centigrade or degrees fahrenheit). A device or a block configuration comprises a set of values for each of the properties of each of the parameters associated with a device or a block.
As noted above, smart field devices are developed so that communication therewith must be performed in one of several available protocols (the HART and Fieldbus protocols, for example). These protocols allow device manufacturers to provide device-specific types of information for a device and, of course, the particular types of information are different for each type of smart field device. Consequently, these protocols are complex and difficult to use in device programming. More particularly, some of these protocols do not provide a completely consistent method for communicating with every smart device conforming thereto. Instead, these protocols, such as the HART protocol, merely provide a way for device manufactures to specify what information is available from each smart field device and how to retrieve that information.
Communication with smart devices has been simplified to some extent with the advent of device description languages (DDL) and device description services (DDS) which are provided by the manufacturers of smart field devices. A DDL is a human-readable language that provides a protocol for describing the data available from a smart device, the meaning of the data associated with the smart device and retrieved therefrom, the methods available for implementation of the smart device, the format for communicating with the smart device to obtain data, user interface information about the device such as edit displays and menus, and for handling or interpreting other information pertaining to a smart device.
DDL source files comprise human-readable text written by device developers. These files specify all the information available about a device between the device and a bus or a host to which the device is connected. Basically, in developing a DDL source file for a device, a developer uses the DDL language to describe core or essential parameter characteristics of the device as well as to provide group-specific, and vendor-specific definitions relating to each block, parameter, and special feature of a smart device.
A DDL source file is compiled into a binary format to produce a machine-readable file known as a device description (DD) which can be provided to a user by the device manufacturer or a third-party developer to be stored in a host system, such as a management system. In some cases, for example in Fieldbus devices, DDL source files may be stored in a smart device and transferred from the smart device to a host system. When the host system receives a DD object file for a smart device, it can decode and interpret the DD to derive a complete description of the interface with the device.
DDS is a general software system developed and provided by Fisher-Rosemount Systems, Inc. and/or Rosemount, Inc. for automatically decoding and interpreting the DD's of smart devices. More particularly, DDS is a library of routines which, when called by a host, interprets the DD of a smart device to provide the host with information pertaining to the smart device, including information pertaining to: (1) the setup and configuration of the smart device; (2) communication with the smart device; (3) user interfaces; and (4) methods available for use in conjunction with the smart device. One extremely useful application of DDS is in providing a consistent interface between a host system and one or more smart devices having associated DDL source files (and corresponding DD object files).
Although DDS, DDL and DD's are generally known in the art, more information pertaining to the specific function and format of DDL's, and of Fieldbus DDL in particular, can be found in the InterOperable Systems Project Foundation's manual entitled "InterOperable Systems Project Fieldbus Specification Device Description Language" (1993), which is hereby incorporated by reference herein. A similar document pertaining to the HART DDL is provided by the HART foundation.
A management system is a system which interacts with one or more smart field devices to read any of the device, block, parameter, variable, or configuration information associated with those devices. Typically, a management system comprises a personal computer having appropriate communication ports which allow it to interconnect to, communicate with, and reconfigure a smart device. Management systems may be on-line, that is, have a hard-wired or other permanent connection with a smart device, management systems may be portable and capable of being periodically connected to a smart device to reconfigure that smart device.
Management systems typically perform a wide variety of functions with respect to smart devices within a system. For example, management systems may be used to provide users with information (e.g., values of variables or parameters) pertaining to the state of a process and to each of the smart field devices associated with or connected to the process. Management systems may also be used to enable a user to monitor a process and control the process by reconfiguring smart devices within the process as necessary.
The software routines which are used to perform functions within a management system using features provided by the system are typically referred to as applications. Typically, management systems implement applications provided by individual smart device manufacturers to implement changes on, and read data from, a particular smart device. As a result, various applications within a management system often do not share a common or consistent interface, and the transition from one application to another is therefore cumbersome and time-consuming. Further, smart device configuration data, configuration logs, and smart device diagnostic data created and stored by different applications are decentralized and cannot be cross-referenced because this data may be stored in diverse formats, in different databases and, in some cases, in proprietary formats. Consequently, tasks that could be common to each device within a system must be duplicated in separate applications.
A management system which implements such separately developed applications typically has no way to view information pertaining to all the smart devices in a plant or a process simultaneously because the applications for each device must be run separately. Furthermore, it is difficult for users to write applications that provide a comprehensive view of data pertaining to multiple, different devices in a process because users typically do not have a great familiarity with DDS or with the DDL and DD's associated with each of the devices within a process. Even if a user does have such familiarity, such applications are time-consuming and expensive to develop and must be updated each time a new smart device is added to the system.
The need for an integrated management system is particularly great in processes or systems which must be certified by government agencies such as the EPA and the FDA, which regulate, for example, certain chemical and pharmaceutical processes to ensure that the products manufactured by those processes meet stringent standards, that emissions remain below a predetermined level, and that safety procedures were followed. The easiest way for a plant implementing a regulated process to maintain its certification is to maintain records sufficiently thorough to prove to government auditors that the values of critical process parameters have remained at specified values or within specified ranges that comply with the regulatory requirements of interested governmental agencies and safety procedures. An integrated management system coupled to the smart devices of a process can be used to automatically record these values in a database. Thereafter, the data stored in the database of the integrated management system can be used to prove that these critical values remained within respective required ranges.
Previously, whenever a management system changed the state of a field device in the control system (i.e., changed any information in the field device), the management system stored, in an internal "state database," a complete new or current "state" for the device. The "state" of a device includes (1) an indication of the time when the change was made (i.e., when the device was put in the new state) and (2) data corresponding to all information stored in the device. The state databases of prior management systems may also have included additional information together with the states of devices (e.g., information about who made the changes to device states or why, etc.).
Maintaining a state database in this fashion, and storing a complete set of variables corresponding to a new state every time a change is made to any field device in the control system, requires a significant amount of storage and processing time. Further, multiple on-line management systems are typically interconnected, and data from each system is combined to form a unified historical database reflecting the state of the entire control system. Although the presence of an indication in the records of the multiple interconnected state databases of the time corresponding to each new state does permit reconciliation of the multiple databases to develop such a unified historical database, it does not overcome the well-known inability of prior-art management systems to interface directly with hand-held communicators and to then reconcile data transferred to the management system from hand-held communicators into the management system database. The reason is that present hand-held communicators, which are quite primitive instruments, do not have internal real-time clocks and therefore cannot apply a time stamp to the state records that the hand-held communicators return to the management system. Consequently, the management system cannot determine the particular point in the chronological, historical database at which to insert a record of a given new state received from the hand-held communicator in order to reconcile that new state with the existing chronological database.
Integrated management systems also can be used to reconfigure smart devices more regularly to maintain the certifiability of the process in which the devices are used. Currently, most management systems which support more than one smart field device include particularized software written for each supported smart device to allow communication with that smart device. Adding a new smart device to a process therefore requires the management system for that process to be reprogrammed. Once again, this programming is time-consuming and can be expensive because it must be performed by a person knowledgeable not only in the management system software, but also in the smart device protocol and the new smart device.
Although hand held communicators exist which interface with different smart devices following a particular protocol, these devices only read and write data from and to the device and are not capable of processing that data in any significant manner.
Another cumbersome aspect of developing applications is programming the application to perform the numerous tasks relating to and necessary for communication between a user and each smart device within a system. A developer not only must be attentive to details involving how to communicate with each separate device, but that developer must also pay particular attention to how information is presented to a user via, for example, a display. This task is made more difficult because typical applications do not use consistent user interface protocols. Each of these functions requires much programming time and effort, which must be repeated each time a new smart device is added to the system.
Still further, applications typically allow a user to view a current configuration of a device, block, or parameter within a process, but those applications do not allow the user to view past configurations or to display multiple configurations simultaneously to compare such configurations.